ElasticBeanstalkのRubyスタックを使い始めて気づいた小ネタ

丹内@re:Invent2015シアトル組です。掲題の小ネタを2点書きます。

RubyスタックではNginxが動いていない

ElasticBeanstalkではNginxが動いており、ebextensionsでその設定を行うことができます。
また、先日の発表によると、.ebextensions/nginx以下からnginx設定ファイルを用意することができるようになりました。
このようにEBでも使うことができるnginxですが、実はrubyスタックではnginxが動いていません。Passengerが80番を受けるためです。
ドキュメントでは確かにPassengerと書いてありましたが、実際にNginxによるアクセス制限を書こうと思うまでは気づきませんでした。
rubyスタックでソースIPによるアクセス制限をかけようとするなら、Security Groupsかアプリケーションで行う必要があります。
passengerでもできるとは思うのですが、.ebextensions/nginxが使えないので、一手間かかります。

Web Tierでrails consoleなどをすると権限でエラー

rubyスタックでRailsを動かす場合、/var/app/current以下にRailsアプリがデプロイされ、bundle execでrailsコマンドを利用することができます。
EB Web TierのEC2にec2-userでsshしてrails consoleを使って作業したり、seedを流したりすることがあるのですが、アプリケーションを動かしているのはwebappというユーザなので、そのままだとログファイル書き込みパーミッション周りでエラーが発生してしまいます。
また、rootで行うと今度はオーナーがrootになったりして、webappユーザで書けなくなってアプリの動作に支障をきたしてしまいます。
穏便に行うには、ELBからアクセスが送られないWeb Tier EC2を立てて、その中でsudoで作業をして、DBやS3に変更が反映されたら作業用EC2を削除してしまうと、簡単・便利です。
例えばsudoersを変更するなどが考えられますが、そうなるとebextensionsが増えてしまったりカスタムAMI管理の手間などもあります。このあたりはケースバイケースですが、私は作業用EC2が「クラウドっぽい」使い捨てな考え方なので好きです。

まとめ

ElasticBeanstalkは、クラウドで動くwebアプリによくあるプラクティスを実装したフレームワークのようなものだと考えています。
学習コストはあるし一部期待した動作をしない部分もありますが、仮に実用しないことを選択した場合でも、プラクティスを実践して学習するという点で非常に有用なサービスです。
私もまだまだEBで不明な点が多いですが、継続して学習していこうと思います。

追記

ところで現在私はre:Invent開催待ちでシアトルにいます。 Amazon創業時に入っていたビルを見れたり、その当時のエピソードが聞けてとても楽しいです。 re:Inventでアメリカに初めて来る際は、ツアーでの参加がオススメです。 以下は、ADSJ小島様が「観覧車乗りましょう〜」と言って有志で乗った観覧車の写真でした。